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FLUSH SUPPORT . O 0 0 4 8 0 

This invention 1. directed to certain hardware and 
software improvements in workstations which utilize virtual 
addressing in multi-user operating systems with write back 
caches, including operating system which allow each user to 
have multiple active processes. In this connection, for 
convenience the invention will be described with reference 
to a particular multi-user, multiple active processes 
operating system, namely the Unix operating system. 
However, the invention is not limited to use in connection 
with the Unix operating system, nor are the claims to be 
interpreted as covering an invention which may be used only • 
with the Unix operating system. 

In a Unix based workstation, system performance may be 
improved significantly by including a virtual address write 
back cache as one of the system elements. The present 
invention describes an efficient scheme for supporting data 
protection and the reassignment of virtual addresses within 
such a system. The invention features support for multiple 
active processes, each with its own virtual address space, 
and an operating system shared by those processes in a 
manner which is invisible to user programs. 

cache -Flush" logic is used to remove selected blocks 
from the virtual cache when virtual addresses are to be 
reassigned. If a range of addresses (a virtual page 
address, for example) is to be reassigned, then all 
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instances of addresses from vithin this range must be 
removed, or -flushed", fro* the cache before the new address 
assignment can.be made. A cache block is "flushed" by 
invalidating the valid bit in its tags and writing the block 
back to memory, if the block has been modified. The "Flush- 
logic includes logic to identify "Flush" commands within 
"Control Space" ; logic to match particular virtual address 
fields, within a Flush command, to corresponding virtual 
address fields either within the cache's block address space 
or its tag virtual address field? and (optional) logic to 
flush multiple cache block addresses as a result of a Bingle 
-Flush" command issued by the CPU (or DVMA device, if 
allowed) . It also includes logic to invalidate the cache 
valid tag on matching cache blocks and logic to enable 
modified matching blocks to be written back to memory. 

The present invention includes both hardware and 
specific "Flush" commands inserted within the operating 
system kernel. 

fPTKF DE.qrPTPTION OF THE DRAWINGS 

Figure 1 is a block diagram showing the main components 
of a workstation utilizing virtual addresses with write back 
cache. 

Figure 2a is a schematic diagram of cache "hit" logic 

25. 



Figure 2b is a scheaatic diagram oC a circuit for 
detecting a cache protection violation. 

Figure 2c is a schenatic diagram of a circuit for 
detecting a KKU protection violation. 

Figure 3 is a detailed block diagram showing the 
address path utilized by the virtual address cache of the • 
present invention. 

Figure 4 (4(a), 4(b)) is a flow diagram of a state 
machine implementation for certain controls related to the 
addressing of a virtual address write back cache. 

Figure 5 is a detailed block diagram ^ showing the data 
path utilized by the virtual address path of the present 
invention. 

Figure 6 (6a, 6b, 6c and 6d) is a flou diagram of a state 
ms chine implementation far certain controls related to data 

transfers to and from a virtual address write back cache 

(states (a) - (o) ) . 

Figure 7 is a flow diagram of a state machine for 
implementation for controlling Write Back bus cycles to 
memory. 

• Figure 8 is a timing diagram for best case timing for 
a cache write miss. 



Figure 9 is a timing diagram for best case timing for 
a oache read miss.- 

Figure 10a is a timing diagram of the memory bus cycle 
for performing a block read cycle. 

t 

Figure 10b is a timing diagram of the memory bus cycle 
for performing a write back cycle. 

Figure 11 is a schematic diagram showing the cache 
flush implementation of the present invention. 

Figure 12 is a schematic diagram showing the logic for 
detection of Context Flush Match, Segment Flush Match and 
Page Flush Hatch. 

Figure 13 (13a - 13e) is a flow diagram of a state 
machine implementation of a cache flush initiated by the 
issuance of a flush command. 

Figure 14 is a timing diagram for a cache flush. 

PTT ftT T^" D Es r pTPTTON ™ ? twp jwvf.ntiow 

Figure 1 shows the functional blocks in a typical 
workstation using virtual addresses in which the present 
invention is implemented. 

Specifically, such a workstation includes a 
microprocessor or central processing unit (CPU) 11, cache 
data array 19, cache tag array 23, cache hit comparator 25, 



MMry management -I* WW) «• « ln » MOry 
buffer 39 end workstation control logic 40. Such 
vocation* may, optionally, also incl.de context ID 
register 32, cache flush logic 33, direct virtual memory 

eccess (DVKA, logic 35, and multiplexor 37. 

in the present invention, various changes are made to 

cache Ilush logic 33, cache hit comparator 25 and 

workstation control logic <Q vhich improve the performance 

of a virtual address write back cache. 

r-.^mtlrm of f-""" Wr,*r of wn r Vstat i °n 

ero 11 issues bus cycles to address instructions and 
data in memory (following address translation, and pos.iMy 
other system devices. The CPU address itself is a virtual 
address cf (A) bits in eUe which uniguely identifies bytes 
of instructions cr data within a virtual context. The bus 
cycle may be characterised by one or more control fields to 
uniquely identify the bus cycle. In particular, a 
*ead/«rite indicator is required, as well as a -Type" ti.ld. 
This field identifies the memory Instruction and data 
address space as well as the access priority (i.e., 
-supervisor" or "User" access priority, for the bus cycle. 
A CPU which may be utilized in a workst.tio'n having virtual 
addressing and capable of supporting a multiuser operating 
system is a MC68020. 
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mother necessary element in a virtual address 
workstation with write back cache shown in Figure 1 i* 
virtual address cache data array 19, vhich is organized as 
an array of 2« 'blocks of data, each of which contains 2« 
bytes . The 2 M bytes within each block are uniquely 
identified with the low order H address bits. Each of the 
2 K b iocks is uniquely addressed as an array element by the 
next lowest K address bits. Xs a virtual address cache, the 
(K+K ) bits addressing bytes within the cache are from the 
virtual address space of (X + C) bits. (The (C) bits are 
context bits from optional context ID register 32 described 
below.) The (N+M) bits include, in general, the (P) 
untranslated page bits plus added virtual bits from the 
(X+C-P) bits defining the virtual page address. 

^ , _ ,4*4-* iirrAV 19 described herein is 
Virtual address cache data array a* 

a "direct »a PP ed» cache, or "one way set associative" cache. 
While this cache organization is used to illustrate the 
invention, it is not meant to restrict the scope of the 
invention which may also be used in connection with multi- 
vay set associative caches. 

Another required element shown in Figure 1 is virtual 
address cache tag array 23 which has one tag array element 
for each block of data in cache data array 19. The tag 
array thus contains 2* elements, each of which has a Valid 
bit (V) , a Modified bit (M) , two protection bits (P) 
consisting of a Supervisor Protect bit (Supvsr Prot, and a 
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Write Allowed bit, and a -virtual address field (VA, and 
optionally CX> as shown in Figure 3. The contents of the 
virtual address field, together vith low order address bits 
used to address the cache tag and data arrays, uniquely 
identify the cache block within the total virtual address 
space of (A+C) bits. That is, the tag virtual address field 
nust contain ((A+C) - (M+K) ) virtual address bits. 

Cache "Hit" logic 25 compares virtual access addresses 
with the contents of the virtual address cache tag address 
field. Within the access address, the lowest. order M bits 
address bytes within a block; the next lowest N bits address 
a block within the cache; and the remaining ((A+C) - (M+N) ) 
bits compare with the tag virtual address field, as part of 
the cache "hit" logic. 

The cache "hit" logic must identify, for systems with a 
shared operating system, accesses to user instructions and 
data, and to supervisor instructions and data. A -hit" 
definition which satisfies these requirements is illustrated 
in Figure 2a which comprises comparators 20, AMD gate 22, OR 
gate 24 and AND gate 26. 

MMU 27, which translates addresses within the virtual 
space into a physical address, is another required element. 
KKU 27 is organized on the basis of pages of size (2*) 
bytes, which in turn are grouped as segments of size (2*) 
pages. Addressing within a page requires (P) bits. These 
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<P> bits are physical address bit. which retire no 
Illation. The role of »» =7 is to translate the virtual 
p e 9 e address bits <(X + C- P > or <X-P)> into physical page 
^dresses of 0»> bit.. The composite physical address is 
the. poi) Page address bits with (P) bits per page. 

„„„ 27 is also the locus for protection checking, i.- . 
comparing the access bus cycle priority vith the protection 
assigned to the page. To illustrate this point, there are 
Wo types of protection that »ay be assigned to a page 
„a*ely, a supervisor/user access designator and a vrite 
Protect/Write Xlloved designator, although the subject 
invention is not lifted to such types of protection, given 
.his page protection, a Protection Violation., can result if 
either a "User., priority bus cycle accesses a page vith 

- m "write" bus cycle accesses 
-supervisor" protection; or if a Write 

e page vith a "Write Protect" designation. 

The application of » protection checking through the 
^ is shown in Figure =c which comprises inverter 2.. *»» 

vith a virtual address write back cache, the concept of 
p r ote=tion Checking can be extended to cache only CPU cydes 
vhich do not access the *». Such cache only protection 
log l = is shown in Figure *b comprising inverter „. XH D 
oetes 44. and 44b, OR gate 46 .nd XHD gate 4B. 
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Also Bhovn in Figure 1 is main memory 31 vhich is 
addressable within' the physical address space; control or 
main memory access is through workstation control logic 40, 

Write back buffer 39 is a register containing one block 
of cache data loaded from cache data array 19. Write back 
buffer 39 is loaded whenever an existing cache block is to 
be displaced. This may be caused by a need to update the 
cache block with new contents , or because the block must be 
flushed. -In either case, in a write back cache, the state 
of the cache tags for the existing cache block determine 
whether this block must be written back to memory. If the 
tags indicate that the block is valid and modified, as 
defined below, then the block contents must be written back 
to memory 31 when the cache block is displaced. Write back 
buffer 39 temporarily holds such data before it is written 
to memory. 

Workstation control logic 4 0 controls the overall 
operation of the workstation elements shown in Figure l. in 
the preferred embodiment, control logic 40 is implemented as 
several state machines which are shown in Figures 4, 6, 7 
and 13 as will be described more fully below in conjunction 
with the description of cache flush logic 33, portions of 
which ajre also, in the preferred embodiment, integrated into 
the workstation control logic. 

Description of Optional Fl.eTnents of Workstation 
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context » register M i. « optional external address 
tl>ltt „ vhich contains further virtual address t,its to 
identify a virtual context cr process. This register, 
containing C mits, identifies a total of < 2 »c, active user 
processes; the total virtual address sp.ee is of .ire 
2**(A+C) 

»» important component in this virtual address space of 
a «(X + C) bits is the address space occupied by the operating 
system. The operating system is common to all user 
processes, and so it is assigned to a common address space 
ac ross all active user processes. That is, the .«« context 
„it. have no meaning in qualifying the addresses of pages 
vithin the operating system, father, the operating system 
U assumed to lie vithin a common, exclusive region at the 
top of the (2..A) bytes of virtual address space for each 
a= tlve context. Ho user pages may lie vithin this region. 
So the operating system page addresses for two distinct user 
processes are identical, vhile the user pages for the tvo 
processes are distinct. All pages vithin the operating 
system are marJced as having -Supervisor- protection. 

cache flush logic 33 is also an optional element in a 

M .v. flush logic 33 is included, and 
workstation. However, cache flush xog 

afl i. detail below in order to improve 
modified as described in detaix o« 

performance of a virtual address, vrite bee* cache 
system. Briefly however, cache flush logic 33 operates as 



follows. If a range of addresses (a virtual page address, 
for example) is to be reassigned, then all instances of 
addresses fro* within this range must be removed, or 
"flushed", from the cache before the new address assignment 
can be made. X cache block is "flushed" by invalidating the 
valid bit in its tags and writing the block back to memory, 
if the block has been modified. 

in addition to CPU 11 as a source of bus cycles, the 
workstation may include one or more external Input/output 
(I/O) devices such as DVKA logic 35. These external I/O 
devices are capable of issuing bus cycles which parallel the 
CPU in accessing one or more -Types" of virtual address 
spaces. The virtual address from either the CPU 11 or DVKA 
logic 35, together with the address in context ID register 
32, is referred to as the access address. 

mother optional element is data bus buffer 37, which 
in the preferred embodiment is implemented as two buffers to 
control data flow between a 32 bit bus and a 64 bit bus. 
Such buffers are needed when the CPU data bus is 32 bits and 
the cache data array data bus is 64 bits. 

r -„^ a n o f Unique to. th* Invented Vo ricst^jon 

in the present invention, the definition of a cache 
..Hit" is modified "to take into account the use of a shared 
operating system across multiple active user contexts, and 
the access priority and page protection. By so doing, an 



, ££i cient indication of * protection violation within the 
vrlte back virtual address cache can be achieved. 
Specifically, to implement the protection definition 
presented above, the following cache .'Hit- definition is 
utilized. 

A cache "Hit" has three requirements: 
D The cache block must be marked as having valid 
contents • 

■2) ignoring the (C) context bits, the access virtual 
eddress bits ( A -(H + «)> must match the corresponding tag 
virtual address field bits <A-(M+M». at the cache 
block addressed by the (M) bus access bits. 

3) Either the (c) bits of the access context ID must 
Batch the corresponding (c) context bits in the cache 
tag virtual address field, or the cache tag supervisor 
protection bit must be set active. 

' This definition of a cache -Hit" enables cache 

protection checking to be applied directly to the virtual 
address cache, rather than defined through an KHU check 
during cache, miss handling. A "Protection Violation" on a 
cache "Hit" results: 

if if the access bus cycle has "User" priority and the 
cache block has "Supervisor" protection; or 



2) if the access is' a Write bus cycle and the cache 
block has Write Protection. 

An implementation of cache hit detector 25 according to the prase 
invention is shown in Figure 2a described hereinabove. 

The present invention utilizes a set of "Flush" 
commands in the Control Space to efficiently implement 
virtual address reassignment in a virtual address vrite back 
cache. 

in general, Flush commands are bus cycles in Control 
Space which specify, for each unique type of Flush command, 
one or more virtual address fields to be compared with 
corresponding virtual address fields, in the- virtual address 
cache tags. "Matching" address fields cause the hardware to 
-flush" the cache block. To "flush" the cache block means 
that: 

1) X matching cache block that is marked as both 
"Valid" and "Modified" is written back to memory. This 
requires a cache block "write back" bus cycle to the main 
aeaory. A "write back" bus cycle writes the contents of an 
entire cache block into main memory at the appropriate 
physical address. As a part of this cycle, the virtual 
address, identifying the cache block 1b translated through 
the MOT into a physical memory address. During this 
translation, protection checking for the cache block is 
inhibited. The address translation through the KMU is 



completed prior to returning control to the processor at the 
conclusion of the flush command. 

2) Xny matching cache block that is -Valid", whether 
-Modified" or not, is marked as invalid. 

As described, the "write back" bus cycle requires the 
translation of the cache block virtual address into a 
physical address. The concept of the flush command and 
"write back" bus cycle can also be extended to virtual 
address caches which contain both virtual address and 
physical address tag fields. If a physical address tag 
field is present, no translation is required at the time the 
-write back" bus cycle to main memory is performed. 
However, the present invention is directed to the use of 
virtual address tags to support a virtual addrese write back 
cache . 

The flush command as described above applies to a 
Bingle cache block. The application of the flush command 
can also be extended so that a single flush command 
activates hardware which checks multiple cache blocks, 
flushing those blocks which match the address fields of the 
flush command. It is only required that the address 
translation of the last cache block flushed be concluded 
prior to returning control to the processor at the 
conclusion of the command. 



Three specific flush commands are defined below. Khile 
other similar commands xay be defined, these three are 
particularly useful in effectively restricting the scope of 
a -Flush" command to a minimal address range. These "Flush- 
commands are also effective in implementing a multiple 
context, shared operating system address space. 

1. Context Match Flush Command 

The Context Match Flush command flushes from the cache 
all cache blocks within a specified context which are from 
User protected pages. It specifies a context identifier of 
(C) bits. The match criteria is to require first, that the 
cache tags identify the block as having User protection; and 
second, that the (C) bit field of the Flush command match 
the corresponding (C) bit Context identification field of 
the tags. 

The Context Match Flush command is used to ensure cache 
addressing consistency whenever a new active context 
replaces an old context in the KKU. The Context Match Flush 
must be performed before the old context references are 
removed from the MKU, since the MMU is required to translate 
the cache blocks' virtual addresses. 

2. -Page Match Flush Command 

The Page Match Flush command flushes from the cache all 
cache blocks within a specified page, regardless of the page 



-. 16 



protection. It epecifies a page address of (A+C-F) bits. 
The match criteria is to require that first, the (A-P) bit 
field of the Flush command, vhich identifies a virtual page 
address within a Context, match the corresponding (A-*) bits 
to identify the virtual page address of a given cache block. 
These (A-P) bits may be in the cache tag virtual address 
field or in a combination of both the cache access address 
and the cache tag virtual address field, depending on the 
page size and the size of the cache. 

The second match criteria is to require that one of the 
following tvo conditions is met: i) the cache block's 
Supervisor access protection tag is active; or ii) the 
context ID register of (O bits match the cache block's 
corresponding Context ID tag field of (C) bits. 

The Page Match Flush command is used during page 
management to purg. all references to a virtual page - with 
either Supervisor or User protection - from the cache. It 
tt ust be performed before the MMU is updated to remove the 
page, since the MMU is required to translate the cache 
blocks' virtual addresses. 

3. segment Match Flush Command 

The Segment Match Flush command flushes from the cache 
all cache blocks within a specified segment, regardless of 
the page protection. It specifies a segment address of 
<(A + C>-(*«» bits, since the segment .ire is (a**.) pages. 



The match criteria is to require that first, the <A-(P+S)) 
bit field of the Flush command, which identifies a segment 
within a Context, match the corresponding <A-(P+S)) bits 
identifying a segment for a given cache block. These <A- 
(P +S) ) bits may be in the cache tag virtual address field or 
in a combination of both the cache access address and the 
cache tag virtual address field, depending on the segment 
size, the page size, and the size of the cache. 

The second match criteria is to require that one of the 
following two conditions is met: i) the cache block's 
Supervisor access protection tag is active; or ii) the 
context ID register of (C) bits match the cache block's 
corresponding Context ID tag field of (C) bits. 

The Segment Match Flush command is used during page 
management to purge all references to a virtual segment - 
with either Supervisor or User protection - from the cache. 
It may be required, depending on the structure of the KMU, 
whenever the pages of an entire virtual segment must be 
reassigned to a new virtual segment. It must be performed 
before the KMU is updated to remove the segment mapping, 
since the KMU is required to translate the cache blocks' 
virtual addresses. ' 



Flush Command Usage 



The three "Flush" commands defined above, together with 
the respective "match" criteria, are executed only by the 



operating system vithin the Unix kernel. The placement of 
flush commands within the kernel is described vithin 
Appendix A. By proper placement of "Flush" commands within 
the kernel, virtual address reassignment for a Unix system 
may be implemented to support a virtual address write back 
cache. 

The set of flush commands defined above, when used in 
the Unix kernel as shown in Appendix A, implement a 
mechanism to support virtual address reassignment, as 
required by a virtual address cache, for a Unix system with 
multiple active contexts and an operating system shared 
across those contexts for workstations having either write 
through or write back caches. 

The flush commands,, when used in the Unix kernel as 
shown in Appendix A, support a virtual address write back 
cache within a Unix system so that the use of «uch a cache 
is transparent to user application programs. No changes are 
required to user programs to take advantage of the memory 
speed improvements inherent in a virtual address write back 
cache. 

Additionally, the flush commands, when used in a Unix 
kernel as shown in Appendix A, support a virtual address 
write back cache implementation which contains only a 
virtual address tag field for block identification, not a 
physical address tag field. Avoiding the addition of a 
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physical address tag field minimizes the number of cache 
tags required for the virtual address write back cache. A 
write back cache requires that at some point, any cache 
block which has been modified must be written back into main 
memory. Shi. "write back" operation may take place either 
when the cache block is replaced by new block contents (the 
normal block replacement on a cache "miss"), or when the 
cache block is flushed prior to reassigning a range of 
virtual addresses containing this cache block. 

If the cache tags contain no physical address field, 
then the virtual address tags must be translated into a 
physical address before the cache block may be written into 
memory. In the case of cache flushes, this implies that all 
address translations of cache block virtual address fields 
which result from a flush match must be completed prior to 
the operating system's reassignment of the virtual address 
range within the KMU. Two features of the invention are in 
part responsible for ensuring that this requirement is met: 

1) first, that the flush command requires the 
completion of the cache block virtual address translation 
before control is returned to the processor; 

2) and second, that the flush commands are structured 
in the kernel, as shown in Appendix A, at strategic 
locations which guarantee the flushing of all modified each, 
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blocks prior to the reassignment of the virtual address 
range . 

The eet of three flush commands defined above, together 
with .their respective H ffiat ch" criteria, constitute an 
efficient virtual address reassignment mechanism when placed 
in the Unix kernel as shown in Appendix A. The mechanism is 
efficient in that it optimizes flush performance for the 
virtual address write back cache for the three cases of 
virtual address reassignment required by the operating 
system; 

1) whenever an existing active context is being 
replaced by a new context; 

2) whenever MKUvlimitations require the reassignment of 
a currently mapped segment to a new segment; and 

3) whenever a physical page in memory is to be 
reassigned to a new virtual address. 

The three flush commands are defined, together with the 
flush match criteria, to specifically cover aach of these 
cases. Flush commands are issued by the kernel by starting 
at a base block address, and then incrementing block 
addresses so as to check every block within a fixed address 
range. -'The flush commands as defined are efficient in 
address reassignment for two primary reasons: 
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1) The flush xaatch criteria restrict the number of 
blocks flushed to be only those blocks which require 
flushing within the flush address range. Other extraneous 
addresses, outside the flush range, are checked but are not 
flushed. 

2) For each of the three cases requiring address 
flushing, the defined flush commands allow the cache to be 
checked with a single pass through the appropriate cache 
block address range. For example, to flush a segment, every 
page within the segment must be flushed. If a segment flush 
were not implemented, then multiple passes of page flush 
commands with varying page addresses might be required to 
complete the segment flush. 

The preferred embodiment of the virtual address cache 
for the address path is shown in Figure 3 and for the data 
path is shown in Figure 5. Flush control logic in the 
preferred embodiment is implemented as showrt in Figures 11, 
12, the state machine of Figure 13 and timing diagram of 
Figure 14. A best case timing diagram for writes is shown 
in Figure 8 and for reads is shown in Figure 9, 

In addition to -components previously discussed with 
reference to Figure 1, Figure 3 includes virtual address 
register (VA*) 5<+ which stores the current virtual address. 
The elements of the invention appear in Figure 3 are cache 
flush logic 33, the Protection bits (P) in the cache tag 



- 22 



array «. and the «u.h -t=h lesio » *** is part of cache hit 

detect log 25. 

Also shown in Figure 5 1b data register 61 which stores 
data to be written to or which has been read iron memory 31 
or cache data array 19. 

in Figures 2, 3, 5, 11 and 12, to avoid unnecessarily 
cluttering the Figures, not all control lines are shown. 
However, the control lines necessary for proper operation of 
the invention can be ascertained from the flow chart of the 
state machines shown in Figures A, 6, 7 and 13, and timing 
diagrams shown in Figures 8-10 and 14. 

In the flow charts, the following abbreviations are 
utilized: 





- multiplexor 45 


Sel 


- eelect 


vx 


- virtual address 




.- real address 


0E 


- output enable 


Ack 


- acknowledge 


Cache Hit? 


- Did cache "hit" logic 25 




detect a cache hit? (Fig 2a) 
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Cache Protect Violation ? - Did control logic 4 0 detect a 

detect a cache protect violation? 

(Fig 2b) 

Memory Busy? - Has Memory Busy been asserted? 
MKU Protect Viol? - Did control logic 40 detect a 

KMU protect violation? 
(Fig 2c) 

KAR - real address register 51 
CLK - clock 
Adr - address 
Mem Adr Strobe - memory 31 address strobe 

VAR - virtual address register 5^ 
Mem Adr Ack? - Has a memory address acknowledge 

been asserted by memory 31? 
Mem Data Strobe 0? - Has memory data strobe 0 been 

asserted? 

Mem Data Ack 0? - Has memory data acknowledge 0 bee 

asserted? 
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„em Data Strobe If - Has »***• 1 

•asserted? 

Hem Data Ac* 1? -H SB . e ..rJto»^« lea " lt,e " 

1 

asserted? 

'd* Krite Back Buffer - clock write back buffer 39 
CPU Sead cycle? - Is CPU 11 in a read cycle 
Clk Data Reg - clock data register 61 
Valid and Modified Write - Has control logic 40 detected . 

Valid bit(V) and Modified bit(M) 

Back Data? 

Start «rite Back Cycle? - Has control logic .0 asserted 

Start Write Back Cycle 
Similar abbreviations are used in the timing diagrams 
of Figures 8-10 &nd 14. 

The address state machine shown in Figures 4a and 4b 
defines certain of the controls related to the address 
handling portion of cache 1.. The cache tags 23 are written 
as valid during state (v) . following a successful transfer 
of all bloc* data from memory 31. The invention Is 
integrand through the inclusion of the Cache Protection 
Violation test following state (=). If a Protection 
Violation is found on a cache Hit. then the CPU bus cycle is 
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terminated immediately «lth » Bus rrror response to the era. 
•The khu Protection Violation on the translated address i. 
performed later, following state (g> . 

The data state machine shown in Figures 6a - 6d define 
certain controXs related to the data transfer portion of the 

*»° mention is supported by including a 
test for the Cache Protection Violation following state (=) . 
The WD Protection Violation test on the translated address 
is similarly performed in state (g) . 

The write back state machine shown in Figure 7 defines 
the control of the write Back bus cycle to memory. This 
cycle may be performed in parallel with CPU cache accesses, 
since both the write Back controls and data path are 
independent of the cache access controls and data path. As 
described below, the -Memory Busy" signal causes the address 
end data state machines to wait until a previous Write Back 
cycle has completed. 

The write cache miss lining diagram shown in Figure 8 
defines the overall timing of a CPU write bus cycle to 
memory which misses the cache. The cache Hit and 
Protection Check occur in cycle (c) in this diagram. 

A part of the miss handling sequence includes the 
loading of the current cache bloc* which is being replaced 
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into write back buffer 39 in cycles (i) and (m) . The 
translated address for the current cache block is also 
loaded into real address register 51 in cycle (o) . If the 
current cache block is both Valid and Modified from a 
previous CPU (or DVHX) write cycle, then this cache block 
vill be vrittten back to memory 31 through a Write Back bus 
cycle, described in both the Memory Data Bus tiding and the 
Write Back state machine, Figures 10 and 7 respectively. 

The CPU write data is merged with block data 
returned from memory on the first data transfer of a 
Block Read memory bus cycle. During cycles (q) through 
(u> , the CPU Write Output Enable controlling buffers 37 
vill be active for only those bytes to be written by 
the CPU, while the Data Register Output Enable 
controlling data register 61 will be active for all 
other bytes. During the second data transfer, cycle 
(v) i the Data Register Output Enables for all bytes 
vill be active. 

The read cache miss timing diagram shown in Figure 9 
defines the overall timing of a CPU read bus cycle to a 
cacheable page in memory which misses the cache. The cache 
Hit and Protection Check occur in cycle (e) in this 
diagram. 

A part of the miss handling sequence includes the 
loading of the current cache block which is being replaced 
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into write back buffer 39 in cycles (i) end (») . The 
translated address for the current cache bloc* is also 
loaded into real address register 51 in cycle (o) . If the 
current cache block is both Valid and Modified from a 
previous CPU (or DVHA) write cycle, -then this cache block 
vill be writtten back to memory 31 through a Write Back bus 
cycle, described in both the Memory Data Bus Timing and the 
Write Back State Machine, Figures 10a and b and 7 respectively. 

Data is read to the CPU by nimultaneously bypassing the 
data to the CPU through buffers 37 enabled by control signal 
CPU Head Output Enable, active in states (q) through (u) , 
and updating the cache, in state («) . The memory is designed 
to always return the "missing data" on the first 64 bit 
transfer, of a Block Read memory bus cycle and the alternate 
64 bits on the subsequent transfer. After the CPU read bus 
cycle data is returned, the CPU may run internal cycles 
while the cache is being updated with the second data 
transfer from memory. 

The Memory Data Bus timing shown in Figure 10a and 10b. 
.hows the timing of Block Read and Write Back bus cycles. 
Since the cache block cize is 128 bits, each cache block 
update requires two data transfers. As indicated above the. 
64 bits containing the data addressed by CPU 11 are always 
returned on the first transfer lor Block Read bus cycles. 
The "Memory Busy" control signal active during the Write 
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Back cycle is used to inhibit the .tart of the next cache 
*i ss cycle until the previous Krite Back cycle can complete. 

cache flush logic 33 shown in Figure 11 outlines the 
control and data path of the flush controller. This 
controller implements the cache flush operations of the 
present invention for a system with multiple active user 
contexts and a shared operating system. Cache flush logic 
comprises AND gate 48, flip-flop. 49, flush address register 
5 2, incrementer 50, AND gates 55 and OR gate 58. 

Three flush match signals are used by cache flush logic 
33 to determine whether the addressed cache bloc* is to be 
flushed. Corresponding to the three flush match signals are 
three flush commands issued by the CPU. A Flush Match is 
said to occur if: 

' (Context Flush Command.) AND (Context Flush Hatch Signal) 
OR (Segment Flush Command ) AND (Segment Flush Hatch Signal) 
OR (Page Flush Command) AND (Page Flush Hatch Signal) . 
An implementation of such flush match logic is shown in 
-Figure 12 comprising comparators 60, AND gate 62, Inverter 
64, OR gate 66 and AND gates 68. 

Flush control logic 33 involves two distinct phases, 
which are shown as separate sequences in the flush state 
machine", Figure 13. The first phase involves decoding a 
Flush command from the CPU and obtaining bus mastership for 
the Flush Control State Machine. The Flush command is 



- 29 



i.su.d by the CPU in control Space (identified by Function 
Cod. bite «f».0>-0«>. Vithln Contro! Space, the four high 
order address bite *(M.H!-«* the WUBh C ° m ' ni - 

«h. address field M27:0) for the commend correspond to the 
*8 bit virtual address field for date access... The Flush 
command data bite BtliO) encode the type of Hush. After 

the Mush commend f *• th ° field X(27!9> lB 

latched toother with the type of flush. * Bu. Revest 
■ignal is asserted to the CPU to obtain bus mastership. 

The second phase involves performing CV*X cycles to 
test and flush, if necessary, 32 cache blocks u«ln 9 cache 
flueh logic 33 as a DVKA device. Thi. CVHX device addresses 
cache blocks with the virtual address *(27: 9 > captured To, 
t*. flush command, plus address bit. A(«.4) from en internal 
5 bit flush address counter 50. too* cache bloc* m.y be 
checked in three cycles, vith the three Flush Match signals 
gated by the Flush command latches 55 to determine a "Fiush 
Hatch- condition. A -Flush Hatch- results in the cache 
block being invalidated and e Modified block being written 
to memory through the Write Back state machine. Following 
the conclusion of the 32 block check, bus mastership m.y be 
returned to the CPU. 

Hote that as a DVMA device, the cache flush logic 33 
compete', vith other DVMA devices for bus ownership. Of the 
possible three DVMA devices, Ethernet (not .houn) has the 
highest priority, the cache flush logic 33 .econd priority, 
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end VKEbus devices third." The flush control state machine 
does not include a complete arbitration description for all 
DVKA devices, ,but rather only logic related to the Flush, 

The cache flush state machine shown in Figure 13 
comprises four interacting machines which control the flush 
operation. These four machines control the decode of the 
CPU Flush command and its application to 32 cache blocks. 
The four machines are described below: 

D The command Decode machine decodes the Flush command 
executed by the CPU. Upon decoding a Flush command, 
the flush virtual address A(27:9) and the type of Flush 
command are latched. The machine asserts a Bus Request 
to the CPU to obtain bus mastership for the flush state 
machine. It aleo asserts a Flush Request signal to 
activate the DVKA machine, below. 

2) The DVKA machine obtains bus mastership from the 
CPU, as indicated by the CPU's asserting Bus Grant, and 
holds mastership by asserting Bus Grant Acknowledge. 

It arbitrates the Flush with the higher priority 
Ethernet requests. 

3) The Flush Compare machine initializes its address 
counter A (8 : 4 } to 0 with the Flush Request, signal. It 
continues to check cache blocks as long as Flush Go is 
asserted by the DVMA machine. When Flush Go is 
deasserted, a Flush Done signal is set at the 
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conclusion of the current Mock flush, which signals 
the DVMA machine to grant mastership to the Ethernet 
handler. If a Flush Match is detected, the Flush Block 
Request signal is asserted to activate the Flush Match 
machine. At the conclusion of the Flush Match machine, 
this machine returns a Write Back Request signal to 
' complete the machine's handling of the current cache 
block. 

4) The Flush Match machine loads the cache data into 
write back buffer 39, clocks the translated cache 
address in real address register. 51, and invalidates 
the cache tags 33. Note that no protection check is 
performed. At the conclusion, the Write Back Request 
signal is asserted. If the cache block is marked as 
Modified, the Start Write Back Cycle signal is also 
asserted to activate the write back state machine shown 
in Figure 7. 

Figure 14 shows cache flush timing and describes the 
timing of a block flush in the event of a "Flush Match". 
This condition is tested in state (c) . The block is 
invalidated in state (k) . If the block satisf ies the "Flush 
Match" and is Modified, then it must be written back to 
memory. A -Start Write Back Cycle" signal is asserted in 
state (s) to begin the Write Back state machine. 
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The kernel changes needed to support the virtual 
address write back cache of the present invention for the 
Unix operating system are shomn in Appendix A. 



Kernel r>e-i^ D oc*~nt for Virtual Addr... 
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3. An Invariant Condition ^ mmm e # the Virtual Address Cache (c*Utd 

thi. li . .«lflel.nt ew.4it.iM> to* cort.rto... of th. .yt- 
beeause of t-he following! w fc Kvf./word from the 

Shila the capping 1. ce "? ct ' "f Jim'th" . SJ.ieal £Sry\hr©ugh >WO 
cache i. the •>»••» £ reading i.^orraet.. 

with the cache being turn# * °"lv be written to'the correaponding 

The byte/word written to the *<>• " lon * »" Y!, k ** P 

phyaieal avemory when * ni, . b ^?^"rd in the cache i» flushed, writing 

capping becocves incorract. 

SI. Cache Flushing 2*£S|SSigf ftfl titte . C onsurriing, vt avoid cache 

T) Sinca cache flushing is ^ x ^ c °/;nir fl -:ehina. a page flush takes 

of aoftware in8t "^t°"; - ddx ««, e «, i£ both virtual addreaaea 
2) For doubly m*PP*6 virtual addre e..», « J arranged to 

can be •cce»»e* ainwltaneoualy, tney na 

ly.tw Sek.ve. •» the """^ " Xix.Vd.vA~m 1. op.n.d. 

sis ;£„r.»rs-1««» nir.Bsx. ■*.«» 

considerably by open /dev/nem. 
^ ^Th^xllTo^ni'routin.. .re added to the kernel, 



X) vae_ctxf luah () fluahaa the etch* by dontext-mateh. It flushes 
all each* linei whoee aupervieor bits In the eaeha tag are off AND whoit 
context Id' a In each* tag* match that of the HWU con tart register. 
I.e. It fluehes an antira uaar context. .*ac_etxfluah (> la dafinad in 
step, a* "* * n 

2) vac_eegflueh(eegraent_number) fluahaa the eaeha by eegoent-siateh. 
It fluahaa all cadhe linoi whoae eegroent addraaa part a (A<1€*27> in SUK-3) 
of tha eaeha tag match "eegmentjnuraber" aithar from a kernel Addraaa 
apaoe or free tha currant oeer'e addraaa space. I.e. it fluahaa aithar 

a kamal eegment or a uaar eegment of tha currant uaar context. 
vacjaegfluehO la dafinad In aap.i. 

3) vae^pagefluahCvirtual^addreee) fluahaa tha oacha by page-match. 
It fluahaa all eaeha Una a whoae paga addraaa parta <A<13*2?> in SUH*3) 

of tha eaeha tag match tha page number part of "virtual addraaa" aithar 
from a karnal addraaa apaca or froca tha currant veer's addraaa apace. 
Z.a. it fluahaa aithar a karnal paga or a uaar paga of tha currant uaar 
context, vacjpagef lueh(} la dafinad In aaap.e. 

4) vae_flttsh(virtual_addreea, number of bytaa) fluahaa tha eaeha 
lines whoa* page addreee parta <A<13-27> in SUN~3) of tha cache taga ara in 
tha rangea of ["vlrtual_address" # •virtual addraaa" + "nuafcer of bytes" - 1J. 
It fluahaa these linaa aithar from a karneT address apaca or ?roca tha 
currant uaar f a addraaa apaca. vac_flush() la used aithar to fluah laaa 
than a paga, auch aa from resume (), or to fluah a number of eontiguoua 
pagaa, auch aa from pageoutQ. vac_flueh() la dafinad in a*p*s. 

5) vac fluahalK) fluahaa tha antira eaeha. Xt la uaad to fluah 
tha antira eaeha to tha phyaical memory bafora wt dump tha physical 
memory from dumpeya () • Zt day alao ba uaad aa an dabugging tool* 
▼ac_fluahall () la dafinad In vmjnaehdep.c. 

€) vac_dieable_kpage (virtual_address) turna off tha caching of 
a kamal paga starting""at "virtual addraaa" 7 Zt la uaad by tha davica 
drivar mmapO routine to anforca tFe eonaiatancy of aharing a karnal paga 
with uaar pagaa. vac_dieable_kpege () la definad in vm_maehdep. c. 

7) vac^enable^kpage (virtual addraaa) turna on tha caching of a 
karnal page atarting at "virtual_adclreee" . If a device drivar snap 
routine know* that no mora uaar pages are aharing a kernel page/ It 
calle vae_enable_kpage {) to allow the caching of thia kernel page. 
<rac_enable_kpage () la definad in vm_machdep.c 

IV * Where and hoy do we fluah the cache ? 

1) We call vac_etxf lueKJT from etxf ree () in vmjnaehdep.c. 
{ CtxfreeO la called when a context la fread from KMU 
and hence the mapping of the whole context la not valid. 
CtxfreeO la called from ctxallocO whan tha oldaat 
context la bumpad out of KMU, from ewapout () when a 
proceee la awapped out/ from exit() whan a proceee 

la terminated, and from ptexpand () when thia context 
la given up before ita pte's are expanded. ) 

2) Me call vac^etxf luah () from vrelvm() in vmproe.e. 

{ Vrelvm() relaaaea tha vm reeourcea aeeocTated with thia 
proceee. Thia will cauae all virtual and phyaical pagaa of 
the proceea ba raleaaad and thua invalidate- all virtual to 
phyaical mappings of the current context. } 

3) He call vac_etxf luah {) from expand <) in vm_proe. e. 

{ Thia happens when a proceaa la ehrinking and it givea back 
aocaa virtual memory. ) 

4) We call vec_ctxf luah () from ovadviee () In kem_sr&an.e. 

{ When the parameter to vadviae() is VAJTLUSB, we invalidata 
all page table entries of the current process. A context flush 
Is more efficient than a number of page fluahaa. } 

5) We call vac_eegf luah () f rom pmegreleaae () in vm_maehdep.c 
f PmeQreleaTe () la called when a pmeq is taken a way. 
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PmegreleaseO can be called by either pmegallocO or 

pmegallocrea () . ) . 
€) We call vac eegf lush 0 from poegload () in ^™»* chd fPi$- , 

{ A aegment~in the hole is to be freed and aet to SEGIHV 

in the segment map. ) 
7) We call vacpageflushO from pageout () in vmpage.e. 

{ This ia wKen a page is marked invalid by the pageout 

demon* ) 

6) We call vact>age flush () from ovadviseO in kem_roan.c. 
{ This ia wEen ovadviseO narks a page invalid. } 

9) We call vac pagef lush () from mapoutO o£ vxn_machdep.c. 
{ MapoutO Ia called to release a mapping from kernel 
virtual address to physical address, 

Mapout () is called from: % 
*) physstrat <) when mapping from kernel virtual addreaa to 
user buffer address is released. - 

b) wraemfreeO 

c) cleanup () 

d) ptexpandO to release old page tables. } 

10) We call vac pagef lush () from pagemove () of vm_machdep . c ♦ 

{ In pagemoveO we call vac_pageflush (to) because the mapping 
of "to* to its physical page is not valid after setpgmapO call* 
We call vac_pagef lush (from) because the mapping of "from" 
to the physical page is not valid after the aecond 
setpgmapO call. ) 

11) We call vaej>agef lush 0 from mbrelse () of aundev/mb.c. 

{ This is when aetpgmap (addr r 0) is called to invalidate 
the mapping from DVMA virtual addresses to physical 
addresses. } 

12) We call vac flush () from resume 0 in vax.a. 

{ At the end~"of context switch time/ the mapping of the 
outgoing process's u becomes invalid. We ahould flush 
the outgoing process's u before its u mapping becomes invalid. 
Since context awitch happens very frequent, we only flushes 
the user struct and the kernel stack , instead of flushing 
the entire u page. (Resume () is also called from procdupO 
to force an update of u.) ) 

13) We call vac_fluah() from sromapO, munmapO, and munmapfd() 
in kern mman.c. 

( Virtual to physical mappings of some pages are changed. ) 

14) We call vac f lushall 0 from dumpsys () of machdep.c to 
flush out the content of the entire vac to physical memory 
in order to dump out the physical memory. 

15) There are a number of places where virtual-to-physical 
mappings are invalidated implicitly/ e.g. the pme/pte mapping 
ia atill valid but this mapping is never used again. We 
must flush the associated portion of cache, otherwise, when 

a new mapping is aet up from this virtual address, the 
cache may contain some lines of the previous mapping. 

a) We call vac pagef lush () f rom mbsetup () of sundev/mb.c. 
{ In mbsetup (), the mapping from pte'a to physical 
pages is temporarily (until mbrelase) replaced by the 
mapping from DVMA virtual addresses. ) 

b) We call vac pagef lush () from dumpsye () of machdep.c. 

1 The last page in the DVMA region is used to map to one 
physical page at a time to dump out the physical memory. 
Such a mapping is invalid each time after (*dumper) O 
is called. ) . . . 

c) We call vac pagef lush () from physstrat O of machdep.c. 
{ In physstrat <), "user- pages are doubly mapped to 
the kernel space. We flush these user pages when we aet 

up the associated kernel pages. Xater, these mappings from 
kernel virtual pages to physical pages are invalidated by 
mapoutO, there these kernel virtual addresses axe 
flushed. } 

d) We call vac paaefluahO from copvseaO of machdep.c. 



{ In copysegO* the mapping from virtual address CXDDR1 
to physical address m pgno m becomes Invalid after copy In O . 

*) Ke call vaepagef lush 0 from snrwO of aun3/mam.c« 

{ In onrwO, the mapping fro© •vnraap" to a physical address 
is set up to copy physical data to the user apace. This 
napping becomes invalid after uiomove 0 * ) 

£) Ke call vacjpagef lush O from page in 0 In vxn_page.c. 

{ The napping from CXDDR1 to physical page pf+i becomes 
invalid after bttro() . ) 

g) Ke call vac flush () f rom procdup () of vmjproc.e 

to flush the kernel stack and u_* parts of forkutl. 

{ In' procdup () r forkutl maps to"the physical u page 

of the child process through vgetuO* 

Since the mapping from forkutl to the physical u page 

of the child becomes invalid when the parent returns from 

procdup () f forkutl la flushed before procdup () returns. 

h) We call vac flush {) from newprocO of kern_fork.c 
to flush the u * part of vfutl. 

{ In newprocOT in the case of.vfork, vfutl soaps to 
the physical page of the child through uaccess(). 
This mapping Is not used anymore after vpassvm() 
is called. ) 

1) Ke call vae_flueh() from awapout O of vm_awap.c 
to flush the* u * part of utl. 

{ In awapout OT mapping from utl, which Is either 
xswaputl or xswap2utl, to the physical u page of proc p 
is invalid after proc p is swapped out. } 
j) Ke call vac flush () from ewapin () of vm_swap.c 
to flush the u * part of utl. 

{ In awapin () , "mapping from ewaputl to the phyaical 

u page of proc p becomes invalid before we return from 

swapin (}. > 

k) Ke call vacjageflush () from swapO of vm_awp.e. 

{ The mapping from i-th virtual page of proceee 2 to 
the physical page is not valid anymore. ) 

1) Ke call vac flush () from pageoutO of vm_page.c 
* to flush the* u * part of pushutl. 

{ In pageoutoT the mapping from pushutl to the physical 
u page of rp becomes invalid after the vtod{) call. ) 

m) Ke call vac flush () from pageoutO of vm_page.c to 
flush the cTuster of pages to be paged out. 
{ SwapO maps the physical pages of these pages to virtual 
addresses of proc[2] before it calls physstrat(). Thus, 
the mappings from the outgoing virtual pages to physical 
pages are to be replaced by those of proc [2] virtual pages 
to these physical pages. Therefore, we flush these pages 
in pageoutO before swapO is called. ) 

n) Ke call vaepagef lush O from kmcopyO of vm_pt.c. 

{ kmcopyO Is called f rom ptexpand () to "copy* pte'e 
from old pte'e to new pte'e. It "copies* by mapinO 
new pte'e to the physical pages of old pte'e. Ke flush 
old pte's before new pte'e are mapped~in. } 

o) Ke call vac_pagef lush () from distpte() of vm p j>t.c. 

{ distpte () is called when the pte entries of a shared 
text pte is changed. For example, pageoutO changes its 
valid bit to invalid. Since other processes sharing this 
text page may have this text psge in the cache, we flush 
out this page for all aharing processes. } 

p) Ke call vacJElushO from vrelpt () of vmjpt.c to flush 
the pte's of the outgoing process. 

{ In vrelpt (), the pages that contains pte's are released 
but map out O la not called. } 
q) Ke call vac_pagef lush 0 from wlokjunlock of 
aunwindowde v/winlock . c • 



{ in wlok unlock (), mapping from wlock->lek_ueer 
to the physioal u page of the current process become 
Invalid if wlock-> lok user is nonxero. > 
r) He cell vac_pagef lush (T from wlokjlene {) of 
aunwindowdev/winlock.e. " 

{ in wlok doneO, the mapping from wloek->lok_«.er 
to the physical u page becomes invalid. J 
16) When protection bits are ehanged and the affected portion 
of the cache should be flushed. Such places axe: 

a) in chcprotO of vm machdep.c, we change the protection 
of teS pages. We'call vac page flush () there to avoid 
having aSy entry in the cadKe with different protection 

b) In^ettproc () of vm machdep.c we change the protection 
bit" of text pages." we call vac_flush(> to flush 

the text part of the process. (settprot O is called 
from vm text.o.) 
el in vac disable kpage () of vm_maehdep.c we call 

vacpage flush (T to flush all cache lines of this page 
before making the page non-cached. 

v Whv don't we flush the cache here ? - 

V. Whv. Sfg^^^j XT-a-Tiit oTplaee. where the mapping from 
virtual addresses to physical addresses are changed but the cache 
Is not flushed. We describe the reasons why cache flushings 

are not J ec J»» ar ^ aB1| () et ^ ^.chdep.c, the virtual to physical 

Sppin? of proc p Is changed to that of proc q. But, q 
gtt5 whatever in the cache previous belong to p, eo no 

? e e ?«Lfo S L C «iJe5"y P vpasspt<> to pass the context of p 
L%? ipaesp? O is calJe^by vpJUv^T which is called before 
Ind aftel vfork(>. vpassvmO passes the ym resources and 
the MMU context of P to q. When vpassvmO returns, the 
virtual ?o physical mapping for the context is not changed. 
Sinleth; context is also passed, the affected mapping, in 
the cache are .till correct, except that now they belong to 
proc q instead of proc p. Therefore, there is no need to 
Kush^he cache either in ctxpassO or in vpassvmO ; > 

2) in vpassptO, the virtual-to-physical mappings of processes 
-up- and "Or are not changed when vpassptO returns. 

(Or more precisely, the mappings » r « * ha ?« e * J*?* *° 
the same as the mappings when vpassptO is entered). 

3) 2n awaVo of vro sv£.c, if -flag- indicates a dirty page 

' Ju.STthe mapping of addr to physical address is replaced 
bv that of the i-th page of procI2) . Since dirty pages 
Save been flushed in P pig.out 0 , there is no need to flush 
"addr" aoain in swap O • , <■ < 

4) in pmegloadO of vm machdep.c, when *pmxp (ctx pmegtseg ) 
' is xero and need, we invalidate pmegt.eg}. Since we did 

either a context flush (in ctxf ree () ) cr a aegment flush 
(in pmegreleaseO) when we set ctx pmegtseg] to xero, 
there is no need to do a segment rt eentiXt 

/ rh«r« are only two places where we set (struct context »)-> 
. ct?5m*g*ngrto aero! One is in pmegreleaseO where we 
vacsegflush(seg) and setsegmap (sag, SEGINV) . ... 
The""other place is in etxfreeO where we call vac_etxf lush () 
but don't setsegroap(seg, SEGINV). 

Hence (struct context *) ->ctx_pmeg [segl is xero but HMD 

•egmap is not SESIKV in this case. The reason that 

when *pmxp — 0 and Ineed in pmegloadO needs a ______ 

set.egmap(.eg, SEGINV) is to make HKJ .egmap to be «JIKV. 
Since we have done a vac_ctxf lush (> <> ' 

•egroent .hould not have any left-over in the 

5) In ctxallocO of vmjnachdep. c, •*tsegmap() is c»ll^ 
to invalidate all mXppinqs from the aeoment map. Since 
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ctxfreeO i« called aarlier to flu.h the 

context, no linea associated with • e ? nan *» 

ace in the cache. Therefore, .egment fltt.he. art »ot 

€) S'StJiynoO o£ ^jnachdep.c, pte.yncO « lls^ P~^i?* d » 

which or', the mod bits to pt.'s and reset **Z"**?lm 4LT*v. 
ihe poeg. Whan we check if another page in this pmeg i. dirty, 
!.Vwv C f« which remensbert the mod bit wa. on. 
E to Jl Hid to «S2 Ihe .eg«ent becau.e pmegrunload turn, 
off the mod bit. in this pmeg. -w^4#**rt 

7) SnloadpgmapO of map., eaves the referenced and modified 
' Sits SenT MOT pne to .oft pte and clear. ^^hese bits in the 
since when we do pageout or .vapout, it i. the .oft 
P?Tthat we Seek ?o delide if a page i. dirty, th««l- no 
Seed to flush the cache when the referenced and modified 

8> p^p^^^nloadpgmapC v, »t.^^ ••JJJ^CJEG, 
SEGINV). In unloadpgmapO, segment map of CSEG is usee *o 
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CLAIMS 



.1. In a workstation utilizing a virtual address write back 
cache including a central processor having an address bus and a 
data bus, a cache data array, having a plurality of cache blocks, 
a cache tag array having an array element for each of said cache 
blocks, each of said array elements having a Valid bit, a Modified 
bit and a Supervisor Protect bit, a write back buffer, a memory 
oanagement unit, a main memory, a cache hit detector, a context 
identification register, flush control logic and workstation 
control logic, the improvement wherein said cache hit detector is 
modified to detect cache hits in a shared operating system across 
multiple active user contexts, and wherein said workstation further 
comprises: 

a) means for reassigning virtual addresses across multiple 
user contexts ; 

b) means for completing a cache block flush operation before 
control is returned to the central processor upon the issuance of a 
flush command, and in each said flush operation, flushing all cache 
blocks having their associated cache tag array element Valid bit 
set, prior to reassignment of the virtual addresses. 

2. The improvement defined by Claim 1 wherein said modified 
cache hit detector comprises: 

a) means for detecting cache blocks having their corresponding 
cache tag array' element Valid bit set; 



b) first means for' determining whether for the cache block 
being addressed by the central processor, said cache block address 
having a plurality of access virtual address bits, said access 
virtual address bits match virtual address field bits in a 
corresponding cache tag array element; 

c) second means for determining whether i) for the cache block 
being addressed by the central processor, said said cache block 
address having a plurality of access context bits, said access 
context bits match context bits in the corresponding cache tag 
array element; and ii) the Supervisor Protect bit is set in the 
corresponding cache tag array element. 

3. The improvement defined by Claim 1 wherein said 
reassigning means comprises: 

a set of flush commands disposed within the shared operating 
system, said flush commands being a context match flush command, a 
page match flush command, and a segment match flush command. 

4. The improvement defined by Claim 1 wherein said flush 
operation completing means comprises: 

a) means for decoding said flush command, said flush command 
being one of a context match flush command, page match flush 
command and segment match flush command; 

b) flush address register means for storing an address 
included in said decoded flush command; 



c) incrementing means for incrementing predetermined address 
bits for combining with the address bits in said flush oddress 
register means; 

d) flush match means coupled to said decoding means for 
generating a flush match logic signal , 

whereby the issuance of a flush command causes all cache 
blocks having their associated Valid bit set to be flushed prior to 
reassignment of the virtual addresses. 

5. The improvement defined by Claim 2 wherein said detecting 
means comprises a first AND gate having a first input coupled to 
the Valid bit of the array element in the cache tag array 
corresponding to the cache block being addressed by the central 
processor. 

'5. The improvement defined by Claim 5 wherein said first 
determining means comprises a first comparator coupled to said 
address bus and said cache tag array, the output of said first 
comparator coupled to a second input of ©aid first AND gate. 

7. The improvement defined by Claim 6 wherein said second 
determining means comprises a second comparator coupled to said 
context identification register and said cache tag array, the 
output of said second comparator coupled to a first input of an XOR 
gate, a second input of said XOR gate coupled to the Supervisor 
Protect bit in the cache tag array element corresponding to the 
cache block addressed by the central processor. 



B. The improvement defined by Claim 7 wherein said modified 
cache hit detector further comprises: 

a) a second AND gate having one input coupled to the output of 
said XOR gate, a, second input coupled to the output of said first 
XND ga te and a third input coupled to the output of a third 
comparator whose inputs are coupled to said address bus and the 
array element of said cache tag array addressed by said central 
processor; 

b) a fourth comparator whose inputs are coupled to Bald 
addr.es bus and the array element of said cache tag array addressed 
by said central processor, the output ot said fourth comparator 
being a third input of said first *HD gate. 

9 . The improvement defined by Claim <• vherein said 

decoding means comprises an AND gate coupled to .aid central 
processor and first, second and third flip-flops having their clocK 
inputs coupled to the output cf said XKD gate and their D-inputs 
coupled to said data bus. 

10. The improvement defined by Claim ? vherein said 

flush address register means comprises a register which loads 
predetermined bits from the address bus when the output of said AKD 
gate is set. 

11. The improvement defined by Claim 9 wherein said 
flush match means comprises first, second and third AHD gates, each 
having one input coupled to the 0 outputs cf eel* first, second and 



third flip-flops respectively and a second input coupled to weans 
Tor generating a segment match signal/ a page jaatch signal and a 
context toatch signal, an OR gate having fir6t, second and third 
inputs coupled respectively to the outputs of said first, second 
and third AKD gates , whereby the output of said OR gate is set when 
oris of said segment, page and context match signals are set and a 
corresponding segment, page and segment command has been decoded. 

12. A workstation substantially as herein described with reference to 
end as illustrated in the accompanying drawings. 
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